Nút RPC Solana: Cài đặt, Nhà cung cấp & Thực tiễn tốt nhất

Các nút RPC Solana cung cấp giao diện đọc, gửi và đăng ký mà các ứng dụng sử dụng để giao tiếp với mạng. Các tính năng của nhà cung cấp, giới hạn, giá cả, yêu cầu phần cứng và số liệu hiệu suất thay đổi theo thời gian, vì vậy các quyết định sản xuất nên được xác minh so với tài liệu hiện tại và các bài kiểm tra khối lượng công việc.

Cập nhật lần cuối: tháng 7 năm 2025

Các điểm cuối công cộng của Solana có thể hữu ích cho việc phát triển nhưng không phải là sự đảm bảo dịch vụ sản xuất phổ quát. Nếu một dApp trả về lỗi 429, bị kẹt khi truy vấn tài khoản hoặc gặp sự cố gửi dưới tải, đường dẫn RPC của nó là một thành phần để điều tra cùng với việc xây dựng giao dịch, phí, đáo hạn, mạng và điều kiện cụm.

Hướng dẫn này bao gồm nút RPC Solana là gì, nó khác với nút xác thực như thế nào, yêu cầu chảy qua hệ thống như thế nào, nơi lấy URL điểm cuối công cộng, phương thức RPC nào quan trọng nhất, cách kết nối qua @solana/web3.js, nhà cung cấp được quản lý nào cần đánh giá, việc tự lưu trữ thực sự yêu cầu những gì và cách khắc phục các lỗi giới hạn tốc độ mà bạn có thể đang gặp phải.

Tóm tắt: Để phát triển, hãy sử dụng các điểm cuối công cộng miễn phí của Solana Foundation. Để sản xuất, hãy sử dụng nhà cung cấp được quản lý như Helius, QuickNode, Alchemy hoặc Triton One. Tự lưu trữ cung cấp nhiều quyền kiểm soát hoạt động hơn nhưng vẫn yêu cầu lập kế hoạch năng lực, chính sách truy cập, giám sát và hướng dẫn phần cứng hiện tại.

Chuyển đến:

• Nút RPC Solana là gì?
• Nút RPC so với Nút xác thực
• Cách Nút RPC Solana Hoạt động
• Các loại Nút RPC Solana
• Tại sao Chất lượng Nút RPC lại Quan trọng: DeFi, NFT và Hiệu suất dApp
• Nhà cung cấp Nút RPC Solana Tốt nhất
• Kết nối Ứng dụng của bạn bằng @solana/web3.js
• Các Phương thức RPC Solana: Bạn có thể Truy vấn những gì
• Cách Chạy Nút RPC Solana Của Riêng Bạn
• Các Lỗi RPC Solana Thường gặp và Cách Khắc phục
• Câu hỏi thường gặp
• Chọn Chiến lược RPC Solana Phù hợp

Nút RPC Solana là gì?

Một nút RPC Solana là một máy chủ triển khai API JSON-RPC của Solana, chấp nhận yêu cầu từ các ứng dụng khách và trả về dữ liệu trạng thái blockchain để phản hồi. Các dApp, ví, trình khám phá khối và tập lệnh tự động sử dụng các nút này để đọc số dư tài khoản, gửi giao dịch và đăng ký các sự kiện trên chuỗi mà không cần duy trì bản sao cục bộ của sổ cái.

Các tài liệu lịch sử trích dẫn thông lượng Solana lý thuyết gần 65.000 TPS và thời lượng slot mục tiêu gần 400 mili giây. Cả hai đều không phải là kết quả thực tế được đảm bảo: định nghĩa giao dịch, các slot bị bỏ qua, lưu lượng truy cập bỏ phiếu, khối lượng công việc, điều kiện cụm và phiên bản phần mềm đều ảnh hưởng đến hiệu suất quan sát được. Tần suất mục tiêu và khối lượng trạng thái tài khoản vẫn đặt ra các yêu cầu đáng kể đối với cơ sở hạ tầng RPC.

Remote Procedure Call (RPC) là một mô hình giao tiếp trong đó một chương trình trên một máy gọi một hàm trên một máy khác như thể nó là cục bộ, với độ phức tạp của mạng được trừu tượng hóa. dApp của bạn có thể truy vấn trạng thái tài khoản và gửi giao dịch trên một nút từ xa thay vì duy trì bản sao sổ cái của riêng mình. Solana sử dụng JSON-RPC 2.0 làm giao thức truyền tải của nó: một định dạng nhẹ định tuyến các lệnh gọi theo tên phương thức qua HTTP hoặc WebSocket, không phải theo đường dẫn URL dựa trên tài nguyên như API REST.

Solana Foundation vận hành các điểm cuối công cộng miễn phí tại https://api.mainnet-beta.solana.com và các URL tương đương cho devnet và testnet. Các điểm cuối này thực thi giới hạn tốc độ trên mỗi địa chỉ IP. Khi ứng dụng của bạn vượt quá giới hạn đó, nó sẽ nhận được lỗi HTTP 429 Too Many Requests, gây ra lỗi không liên tục và trải nghiệm người dùng suy giảm dưới tải.

Nút RPC so với Nút xác thực: Hiểu rõ sự khác biệt

Một nút RPC phục vụ dữ liệu blockchain cho các máy khách bên ngoài thông qua API JSON-RPC. Một nút xác thực tham gia vào quá trình đồng thuận và bỏ phiếu về tính hợp lệ của khối. Đây là hai loại nút chính trên Solana và chúng phục vụ các mục đích riêng biệt.

Các nút xác thực tham gia vào quá trình đồng thuận Tower BFT, một cơ chế bỏ phiếu dựa trên Proof-of-Stake. Proof of History (PoH), cơ chế sắp xếp mật mã của Solana (không phải giao thức đồng thuận của nó), thiết lập thứ tự trước khi bỏ phiếu được đưa ra. Tower BFT là lớp đồng thuận; PoH xử lý việc ghi lại thời gian.

Gulf Stream, giao thức chuyển tiếp giao dịch của Solana, gửi giao dịch trực tiếp đến các nút lãnh đạo hiện tại và sắp tới, bỏ qua mempool mà các blockchain khác sử dụng. Các nút xác thực xử lý quy trình chuyển tiếp này. Nút RPC thì không.

Việc chạy một nút RPC không yêu cầu SOL đã stake. Một số nhà điều hành chạy cả chức năng xác thực và RPC trên cùng một máy vật lý, nhưng các vai trò vẫn tách biệt về mặt logic: một nút bỏ phiếu trong đồng thuận, nút còn lại phục vụ các truy vấn của máy khách. Đối với các yêu cầu phần cứng liên quan đến việc tự lưu trữ một nút RPC, yêu cầu RAM và dung lượng lưu trữ sẽ cao hơn đáng kể so với chỉ một nút xác thực.

Cách Nút RPC Solana Hoạt động: Kiến trúc và Luồng dữ liệu

Một nút RPC Solana duy trì một bản sao cục bộ của sổ cái và trạng thái tài khoản, phục vụ dữ liệu đó cho bất kỳ máy khách nào gửi yêu cầu JSON-RPC hợp lệ.

Vòng đời yêu cầu JSON-RPC

1. Một ứng dụng khách (dApp, ví hoặc tập lệnh) gửi yêu cầu POST HTTP hoặc tin nhắn WebSocket đến URL điểm cuối của nút RPC.
2. Thân yêu cầu chứa một payload JSON-RPC 2.0 với bốn trường: jsonrpc, id, method, params.
3. Nút RPC nhận yêu cầu và định tuyến nó đến trình xử lý nội bộ thích hợp dựa trên trường method.
4. Nút truy vấn bản sao sổ cái cục bộ hoặc kho lưu trữ trạng thái tài khoản để lấy dữ liệu được yêu cầu.
5. Nút trả về một phản hồi được mã hóa JSON chứa dữ liệu được yêu cầu hoặc đối tượng lỗi có cấu trúc.

Một ví dụ cụ thể về getBalance:

// Yêu cầu
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBalance",
  "params": ["YourPublicKeyBase58Here", {"commitment": "confirmed"
}


// Phản hồi
{
  "jsonrpc": "2.0",
  "result": {
    "context": {"slot": 285823400},
    "value": 5000000000
  },
  "id": 1
}
// Lưu ý: giá trị tính bằng lamports. Chia cho 1.000.000.000 để chuyển đổi sang SOL.

Không giống như API REST sử dụng URL dựa trên tài nguyên, JSON-RPC định tuyến mọi lệnh gọi thông qua một điểm cuối duy nhất bằng trường method. Các nhà phát triển có kinh nghiệm về Ethereum sẽ nhận ra cấu trúc yêu cầu. Solana khác biệt ở ba điểm chính: không có mempool (giao dịch đi trực tiếp đến lãnh đạo hiện tại), trạng thái nằm trong các tài khoản thay vì bộ nhớ hợp đồng EVM, và các slot 400ms nhanh hơn khoảng 30 lần so với thời gian khối 12 giây của Ethereum.

Các cấp độ cam kết: processed, confirmed, finalized

Mọi lệnh gọi RPC đọc trạng thái đều chấp nhận tham số commitment:

• processed: Slot gần đây nhất mà nút đã thấy. Nhanh nhất, nhưng slot đó về mặt lý thuyết có thể bị hoàn tác.
• confirmed: Slot đã nhận được đa số phiếu bầu từ các trình xác thực. Độ cuối cùng mạnh mẽ cho hầu hết các trường hợp sử dụng dApp.
• finalized: Slot là một phần vĩnh viễn của chuỗi. Sử dụng cho các hoạt động có rủi ro cao.

Nút RPC Solana Lưu trữ những gì

Nút (node) lưu trữ hai loại dữ liệu. Trạng thái tài khoản hiện tại nằm trong RAM: ảnh chụp nhanh (snapshot) của mọi tài khoản đang hoạt động tại khe (slot) được xác nhận mới nhất, cần thiết để phản hồi truy vấn nhanh. Dữ liệu sổ cái lịch sử nằm trên ổ SSD NVMe: tất cả các hồ sơ giao dịch được sắp xếp theo khe. Solana tích lũy khoảng 100 đến 200 GB dữ liệu sổ cái mỗi ngày trên Mainnet-beta. Sự tăng trưởng lưu trữ đó, kết hợp với các khe thời gian 400ms, giải thích lý do tại sao các nút RPC yêu cầu tối thiểu 256 GB RAM và nhiều terabyte lưu trữ nhanh.

Để xem tài liệu tham khảo đầy đủ về Solana JSON-RPC API, hãy truy cập docs.solana.com/api.

HTTP so với WebSocket: Chọn phương thức truyền tải phù hợp

Các loại nút Solana RPC: Công khai, Riêng tư và Tự vận hành

Các nút Solana RPC được truy cập thông qua ba cách: qua các điểm cuối công khai miễn phí của Solana Foundation, qua một nhà cung cấp riêng tư được quản lý, hoặc qua một nút tự vận hành do bạn trực tiếp điều hành.

Điểm cuối Solana RPC công khai (Miễn phí)

Solana Foundation vận hành bốn điểm cuối RPC công khai, một điểm cho mỗi cụm mạng. Tất cả đều miễn phí nhưng áp dụng giới hạn tốc độ trên mỗi địa chỉ IP.

Các điểm cuối công khai áp dụng giới hạn tốc độ khoảng 100 yêu cầu mỗi 10 giây cho mỗi địa chỉ IP. Vượt quá ngưỡng này sẽ trả về lỗi HTTP 429 Too Many Requests. Các điểm cuối này hoạt động tốt cho việc phát triển và thử nghiệm. Để sử dụng thực tế, hãy xem bảng so sánh các nhà cung cấp Solana RPC bên dưới.

Để xem tài liệu đầy đủ về các cụm mạng, hãy truy cập docs.solana.com/clusters.

Các nhà cung cấp nút RPC riêng tư và được quản lý

Một nhà cung cấp RPC được quản lý có thể cung cấp các điểm cuối chuyên dụng, giới hạn công bố cao hơn, hỗ trợ WebSocket, các mục tiêu dịch vụ và nhiều khu vực địa lý; các tính năng chính xác phụ thuộc vào gói dịch vụ hiện tại. Bốn nhà cung cấp chính cho Solana là:

• Helius: Nhà cung cấp chuyên biệt cho Solana với các API RPC nâng cao và thông báo Webhook
• QuickNode: Nhà cung cấp đa chuỗi với sự phân bổ địa lý và thị trường tiện ích bổ sung
• Alchemy: Nhà cung cấp đa chuỗi với các công cụ phát triển cấp doanh nghiệp
• Triton One: Chuyên gia về Solana tập trung vào hiệu suất RPC thô cho các khối lượng công việc của tổ chức

Bảng so sánh đầy đủ về giá cả, hỗ trợ WebSocket và các điểm khác biệt nằm trong phần so sánh nhà cung cấp.

Nút Solana RPC tự vận hành

Tự vận hành mang lại cho bạn toàn quyền kiểm soát cơ sở hạ tầng RPC của mình mà không bị giới hạn tốc độ, nhưng chi phí phần cứng bắt đầu từ hàng nghìn đô la và việc bảo trì DevOps liên tục là không hề đơn giản. Các yêu cầu đầy đủ và tổng quan về thiết lập nằm trong mục Cách chạy nút Solana RPC của riêng bạn.

Tại sao chất lượng nút RPC lại quan trọng: DeFi, NFT và hiệu suất dApp

Chất lượng của nút RPC trực tiếp quyết định liệu ứng dụng của bạn có hoạt động chính xác trong các điều kiện thực tế hay không. Bốn trường hợp sử dụng sau đây sẽ làm rõ điều này.

Bot giao dịch và Chênh lệch giá DeFi

Các giao thức DeFi trên Solana xử lý các giao dịch nhạy cảm với thời gian, nơi độ trễ quyết định kết quả. Một Bot giao dịch gọi các hàm getLatestBlockhash và sendTransaction thông qua một điểm cuối công khai bị giới hạn tốc độ sẽ có nguy cơ gặp phải blockhash cũ hoặc giao dịch bị hủy trong thời gian chờ lỗi 429. Trên dòng thời gian khe 400ms của Solana, sự chênh lệch 50ms trong thời gian phản hồi RPC có thể quyết định việc một giao dịch có lọt vào khe mục tiêu hay bỏ lỡ hoàn toàn.

Jupiter (công cụ tổng hợp), Raydium (AMM/DEX), Drift (hợp đồng vĩnh cửu) và Marginfi (cho vay) đều phụ thuộc vào quyền truy cập RPC độ trễ thấp. Không giống như Mempool của Ethereum DeFi, các giao dịch Solana bỏ qua Mempool hoàn toàn thông qua Gulf Stream, đi thẳng đến người dẫn đầu (leader) hiện tại. Không có hàng đợi sắp xếp nào để dựa vào nếu lệnh gọi RPC của bạn đến muộn.

Theo dõi thị trường và đúc NFT

Việc đúc NFT với nhu cầu cao sẽ tạo ra các đợt bùng phát hàng trăm lệnh gọi sendTransaction đồng thời từ những người mua cạnh tranh cho nguồn cung hạn chế. Một điểm cuối công khai bị giới hạn ở mức khoảng 10 yêu cầu mỗi giây sẽ trả về lỗi 429 cho hầu hết những người tham gia trong thời điểm mở bán cao điểm. Các thị trường NFT như Magic Eden và Tensor sử dụng các đăng ký WebSocket logsSubscribe để phát hiện các sự kiện đúc theo thời gian thực, điều này yêu cầu một nhà cung cấp có khả năng xử lý các kết nối WebSocket ổn định ở quy mô lớn.

Các ứng dụng ví gọi getBalance và getTokenAccountBalance cho mỗi tài sản mà người dùng nắm giữ, cộng với getAccountInfo để đọc siêu dữ liệu Trên chuỗi. Một ví phục vụ 10.000 người dùng hoạt động có thể phát ra hàng chục nghìn truy vấn RPC mỗi phút. Một nhà cung cấp RPC riêng tư với công suất QPS (truy vấn mỗi giây) đủ lớn sẽ giúp các truy vấn này được giải quyết mà không làm giảm trải nghiệm người dùng. QPS ở đây đề cập đến thông lượng yêu cầu RPC, không phải thông lượng giao dịch cấp mạng của Solana.

Các nền tảng phân tích và lập chỉ mục gọi getBlock liên tục để sao chép toàn bộ lịch sử giao dịch của sổ cái Solana. Một quá trình đồng bộ hóa lịch sử đầy đủ sẽ phát ra hàng nghìn yêu cầu getBlock liên tiếp. Các nút RPC tự vận hành hoặc các gói cấp doanh nghiệp chuyên dụng là những lựa chọn duy nhất duy trì khối lượng này một cách đáng tin cậy. Các sàn giao dịch tập trung tự vận hành các nút Solana RPC của riêng họ cũng sử dụng các mô hình thông lượng cao tương tự để đối soát số dư người dùng và phát hiện các khoản tiền gửi ở quy mô lớn.

Thời gian khe 400ms của Solana so với thời gian khối khoảng 12 giây của Ethereum có nghĩa là một dApp trên Solana truy vấn RPC thường xuyên hơn gấp khoảng 30 lần trên mỗi đơn vị thời gian cho các hoạt động tương đương, khiến hiệu suất nút RPC trở nên cực kỳ quan trọng ở đây hơn so với hầu hết các mạng khác. Nếu bạn đang gặp giới hạn tốc độ trong lưu lượng truy cập thực tế, việc nâng cấp lên nhà cung cấp RPC riêng tư là cách khắc phục trực tiếp nhất.

So sánh các nhà cung cấp nút Solana RPC

Đối với hầu hết các dApp thực tế, câu hỏi không phải là có nên sử dụng nhà cung cấp RPC được quản lý hay không, mà là nhà cung cấp nào phù hợp với khối lượng công việc của bạn. Bảng này bao gồm bốn lựa chọn chính với điểm cuối công khai miễn phí của Solana Foundation làm chuẩn cơ sở.

Thông tin giá trong bảng này chính xác tại thời điểm xuất bản. Các gói, giá cả và tính năng của nhà cung cấp thay đổi thường xuyên. Vui lòng xác minh chi tiết hiện tại trực tiếp trên trang web của mỗi nhà cung cấp trước khi đưa ra lựa chọn.

Cập nhật lần cuối: Tháng 7 năm 2025

Helius quảng cáo các phương thức RPC tập trung vào Solana, webhooks và các tính năng phân tích giao dịch. Khả năng, hạn ngạch, giá cả, khu vực và các điều khoản dịch vụ nên được kiểm tra trực tiếp tại helius.dev và thử nghiệm với khối lượng công việc dự kiến.

QuickNode quảng cáo cơ sở hạ tầng RPC đa chuỗi, các điểm cuối khu vực và các tiện ích bổ sung tùy chọn. Xác minh phạm vi bao phủ Solana hiện tại, hạn ngạch, giá cả và các điều khoản dịch vụ tại quicknode.com, sau đó đo lường hiệu suất của các phương thức và khu vực cần thiết.

Alchemy quảng cáo cơ sở hạ tầng dành cho nhà phát triển đa chuỗi bao gồm hỗ trợ Solana. Xác nhận phạm vi bao phủ phương thức hiện tại, hoạt động WebSocket, giới hạn, khu vực và giá cả tại alchemy.com trước khi coi nó tương đương với nhà cung cấp khác.

Triton One quảng cáo cơ sở hạ tầng Solana cho khối lượng công việc thông lượng cao hơn. Độ trễ, tính khả dụng, phạm vi bao phủ địa lý, giới hạn và các điều khoản thương mại của nó yêu cầu xác minh trực tiếp tại triton.one và kiểm tra theo khối lượng công việc cụ thể.

GenesysGo trước đây vận hành dịch vụ RPC Solana dưới thương hiệu Shadow. Xác minh tình trạng hiện tại tại genesysgo.com trước khi đánh giá.

Tất cả các nhà cung cấp lớn đều cung cấp các gói miễn phí hoặc dùng thử đủ cho việc phát triển và thử nghiệm. Giới hạn tốc độ chỉ trở thành mối quan tâm sản xuất khi ứng dụng của bạn phục vụ người dùng thực ở quy mô lớn.

Cách đánh giá Nhà cung cấp RPC Solana

Nhà cung cấp phù hợp phụ thuộc vào khối lượng công việc của bạn:

Các tuyên bố về độ trễ của nhà cung cấp không thể thay thế cho nhau. p50 là thời gian phản hồi trung bình, trong khi p99 là 1% yêu cầu chậm nhất và có thể quan trọng đối với các hoạt động nhạy cảm về thời gian. Kết quả thực tế phụ thuộc vào hỗn hợp phương thức, tải, khoảng cách địa lý, bộ nhớ đệm và giới hạn gói, vì vậy hãy đo lường mẫu yêu cầu dự kiến trước khi chọn gói trả phí.

Kết nối Ứng dụng của bạn với Node RPC Solana Sử dụng @solana/web3.js

Chuyển từ điểm cuối công khai của Solana Foundation sang nhà cung cấp riêng tư chỉ yêu cầu thay đổi một dòng trong ứng dụng của bạn: chuỗi URL được truyền vào hàm tạo Connection.

Lưu ý về phiên bản: Các ví dụ mã trong phần này sử dụng @solana/web3.js v1.x, tiêu chuẩn sản xuất hiện tại. Solana Labs đang phát triển v2.0 với API khác biệt đáng kể. Nếu bạn đang sử dụng v2.0, hãy tham khảo tài liệu chính thức của v2.0 cho các phương thức tương đương.

Cài đặt và Kết nối

Bước 1: Cài đặt gói

npm install @solana/web3.js

Bước 2: Khởi tạo Connection và truy vấn Số dư

import { Connection, PublicKey, LAMPORTS_PER_SOL } from "@solana/web3.js";

// Lấy điểm cuối từ biến môi trường — không bao giờ mã hóa cứng URL riêng tư
const RPC_ENDPOINT = process.env.RPC_URL ?? "https://api.devnet.solana.com";

const connection = new Connection(RPC_ENDPOINT, "confirmed");

async function getWalletBalance(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

// getBalance trả về lamports; chia cho LAMPORTS_PER_SOL (10^9) để lấy SOL
  const balanceLamports = await connection.getBalance(publicKey);
  const balanceSOL = balanceLamports / LAMPORTS_PER_SOL;

  console.log(`Số dư: ${balanceSOL} SOL`);
}

**Bước 3: Đọc dữ liệu tài khoản**

async function getAccountData(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

// getAccountInfo trả về null nếu tài khoản không tồn tại
  const accountInfo = await connection.getAccountInfo(publicKey);

  if (!accountInfo) {
    console.log("Tài khoản không tìm thấy");
    return;
  }

  console.log("Chương trình sở hữu:", accountInfo.owner.toBase58());
  console.log("Độ dài dữ liệu (byte):


**Bước 4: Gửi một giao dịch**

import {
  Transaction,
  SystemProgram,
  Keypair,
  sendAndConfirmTransaction,
} from "@solana/web3.js";

async function transferSOL(
  sender: Keypair,
  recipientAddress: string,
  amountSOL: number
): Promise<string> {
  const recipient = new PublicKey(recipientAddress);
  const lamports = amountSOL * LAMPORTS_PER_SOL;

  const transaction = new Transaction().add(
    SystemProgram.transfer({
      fromPubkey: sender.publicKey,
      toPubkey: recipient,
      lamports,
    })
  );

  // sendAndConfirmTransaction chờ cho đến khi cam kết "confirmed" trước khi giải quyết
  const signature = await sendAndConfirmTransaction(connection, transaction, [sender]);
  return signature;
}

**Bước 5: Cấu hình chuyển đổi điểm cuối dựa trên môi trường**

Thiết lập một module cấu hình để hoán đổi các cụm thông qua biến môi trường thay vì sửa đổi mã ứng dụng:

// config/rpc.ts
const RPC_ENDPOINTS: Record<string, string> = {
  "mainnet-beta": "https://api.mainnet-beta.solana.com",
  "devnet":       "https://api.devnet.solana.com",
  "private":      process.env.PRIVATE_RPC_URL ?? "",
};

const NETWORK = process.env.SOLANA_NETWORK ?? "devnet";
export const connection = new Connection(RPC_ENDPOINTS[NETWORK], "confirmed");

**Lưu ý bảo mật:** Không bao giờ mã hóa cứng URL điểm cuối RPC riêng của bạn trong JavaScript phía máy khách. URL được hiển thị trên trình duyệt sẽ làm lộ API key của bạn cho bất kỳ ai kiểm tra lưu lượng mạng. Hãy chuyển nó qua proxy phía máy chủ hoặc API route backend.

Để tham khảo toàn bộ API của @solana/web3.js, hãy xem [solana-labs.github.io/solana-web3.js](https://solana-labs.github.io/solana-web3.js/).

### Kết nối RPC qua HTTP so với WebSocket: Khi nào sử dụng

| Kịch bản | Sử dụng HTTP | Sử dụng WebSocket |
|---|---|---|
| Lấy Số dư ví một lần | Có | Không |
| Gửi một giao dịch | Có | Không |
| Theo dõi một tài khoản để biết các thay đổi theo thời gian thực | Không | Có |
| Truyền nhật ký giao dịch cho một chương trình | Không | Có |
| Theo dõi việc xác nhận một chữ ký cụ thể | Không | Có |

Các kết nối WebSocket sử dụng `wss://` thay vì `https://`. Hầu hết các nhà cung cấp được quản lý đều cung cấp cả hai điểm cuối trong cùng một gói.

// Đăng ký WebSocket: theo dõi thay đổi tài khoản trong thời gian thực
const publicKey = new PublicKey("YourAccountPublicKeyHere");

const connectionWithWS = new Connection(
  process.env.RPC_URL ?? "https://api.devnet.solana.com",
  {
    commitment: "confirmed",
    wsEndpoint: process.env.WSS_URL ?? "wss://api.devnet.solana.com",
  }
);

// onAccountChange trả về một subscription ID được sử dụng để dọn dẹp sau này
const subscriptionId = connectionWithWS.onAccountChange(
  publicKey,
  (accountInfo, context) => {
    console.log("Tài khoản đã thay đổi tại slot:", context.slot);
    console.log("Số dư lamport mới:", accountInfo.lamports);
  },
  "confirmed"
);

// Gỡ bỏ đăng ký khi không còn cần thiết:
// connectionWithWS.removeAccountChangeListener(subscriptionId);

Xử lý Giới hạn Tần suất (Rate Limits) và Lỗi 429

Lỗi 429 Too Many Requests từ một điểm cuối (endpoint) Solana công cộng có nghĩa là ứng dụng của bạn đã vượt quá giới hạn tần suất trên mỗi IP. Có ba chiến lược để giải quyết vấn đề này:

1. Chuyển sang nhà cung cấp dịch vụ riêng được quản lý. Helius, QuickNode, Alchemy và Triton One cung cấp các gói dịch vụ được thiết kế cho lưu lượng truy cập thực tế. Xem phần so sánh các nhà cung cấp Solana RPC riêng.
2. Triển khai cơ chế exponential backoff (thử lại lũy thừa). Khi nhận phản hồi 429, hãy thử lại với một khoảng thời gian trễ tăng gấp đôi sau mỗi lần thử (xem mã bên dưới).
3. Đọc tài khoản theo lô với getMultipleAccounts. Lấy dữ liệu của 20 tài khoản trong một lần gọi chỉ tiêu tốn một yêu cầu thay vì 20.

// Wrapper exponential backoff cho bất kỳ lệnh gọi RPC nào
async function withRetry<T>(
  fn: () => Promise<T>,
  maxRetries: number = 5
): Promise<T> {
  let attempt = 0;
  while (attempt < maxRetries) {
    try {
      return await fn();
    } catch (error: any) {
      const is429 = error?.message?.includes("429");
      if (is429 && attempt < maxRetries - 1) {
        // Đợi 500ms, sau đó là 1s, 2s, 4s, 8s
        const waitMs = 500 * Math.pow(2, attempt);
        await new Promise((resolve) => setTimeout(resolve, waitMs));
        attempt++;
      } else {
        throw error;
      }
    }
  }
  throw new Error("Đã vượt quá số lần thử lại tối đa");
}

Các Phương thức Solana RPC: Những gì bạn có thể truy vấn

API JSON-RPC của Solana cung cấp hơn 80 phương thức. Bảng dưới đây bao gồm các phương thức mà hầu hết các nhà phát triển dApp thường xuyên sử dụng.

Các Phương thức HTTP RPC

getRecentBlockhash đã bị loại bỏ. Hãy sử dụng getLatestBlockhash thay thế. Phương thức thay thế này cũng trả về lastValidBlockHeight, cho phép xử lý Đáo hạn giao dịch một cách đáng tin cậy.

Các Phương thức Đăng ký WebSocket

Đăng ký WebSocket phù hợp cho bất kỳ dApp nào cần phản ứng với các sự kiện trên chuỗi mà không cần thăm dò (polling). accountSubscribe kích hoạt khi dữ liệu của một tài khoản cụ thể thay đổi, hữu ích cho việc theo dõi ví của người dùng hoặc tài khoản trạng thái của một chương trình Solana (tương đương với một Hợp đồng Thông minh trên Ethereum). logsSubscribe truyền phát các nhật ký giao dịch khớp với bộ lọc ID chương trình, được các giao thức DeFi như Jupiter và Raydium sử dụng để phát hiện các sự kiện hoán đổi (swap) khi chúng xảy ra.

Anchor, khung phát triển chương trình Solana được sử dụng rộng rãi nhất, tạo ra các TypeScript client gọi các phương thức này thông qua @solana/web3.js ở bên dưới. Cấu hình RPC được áp dụng tương tự cho các dApp dựa trên Anchor.

Để xem tài liệu tham khảo phương thức đầy đủ bao gồm các tham số, kiểu trả về và mã lỗi, hãy xem Tài liệu API Solana RPC.

Cách chạy Node Solana RPC của riêng bạn: Yêu cầu và Tổng quan Cài đặt

Tự lưu trữ một node Solana RPC mang lại cho bạn sự kiểm soát hoàn toàn, không bị giới hạn tần suất và quyền riêng tư dữ liệu tối đa. Việc đầu tư phần cứng có thể tốn hàng nghìn đô la, và việc duy trì node hoạt động ổn định đòi hỏi năng lực DevOps chuyên dụng. Các giao thức lớn, sàn giao dịch và các nhóm có khả năng hạ tầng sẵn có là đối tượng cho lộ trình này.

Yêu cầu Phần cứng

Yêu cầu phần cứng thay đổi khi mạng lưới phát triển. Hãy xác minh các thông số kỹ thuật hiện tại với tài liệu chính thức của Solana tại docs.solana.com/running-validator trước khi trang bị phần cứng.

Mô hình dựa trên tài khoản của Solana lưu trữ tất cả trạng thái chương trình trong các tài khoản riêng lẻ. Một node RPC đầy đủ phải giữ trạng thái tài khoản hiện tại cho mọi tài khoản đang hoạt động trong RAM để phản hồi truy vấn nhanh chóng, cộng với dữ liệu sổ cái lịch sử trên NVMe SSD. Sự tăng trưởng lưu trữ từ 100 đến 200 GB mỗi ngày trên Mainnet-beta có nghĩa là các nhà vận hành phải lập kế hoạch cho việc luân chuyển sổ cái liên tục.

Tổng quan Quy trình Thiết lập

Cần có bảy giai đoạn. Mỗi bước đều liên kết đến tài liệu chính thức của Solana để biết chi tiết cấu hình đầy đủ.

1. Chuẩn bị phần cứng đáp ứng hoặc vượt quá các thông số kỹ thuật trên.
2. Cài đặt hệ điều hành và cấu hình các tham số nhân Linux: nâng giới hạn trình mô tả tệp ulimit và điều chỉnh cài đặt mạng sysctl cho khối lượng lưu lượng UDP cao của Solana.
3. Cài đặt Solana CLI và tệp thực thi validator agave (trước đây là solana-validator) từ kênh phát hành chính thức của Solana Labs.
4. Cấu hình node cho chế độ RPC bằng cách truyền cờ --no-voting để tắt tính năng tham gia đồng thuận, và đặt --rpc-port 8899 (HTTP) và --rpc-pubsub-port 8900 (WebSocket).
5. Tải xuống một snapshot từ kho lưu trữ snapshot của Solana Foundation để khởi động đồng bộ hóa từ một trạng thái gần đây thay vì phát lại từ genesis.
6. Khởi động node và theo dõi tiến trình đồng bộ hóa bằng cách sử dụng solana catchup để theo dõi node đang chậm hơn bao nhiêu so với đầu cụm (cluster tip).
7. Cấu hình các quy tắc tường lửa để chỉ mở các cổng 8899 và 8900 cho các địa chỉ IP được ủy quyền. Không để cổng RPC của bạn ở chế độ công khai mà không có xác thực.

Thời gian Đồng bộ hóa và Bảo trì Thường xuyên

Đồng bộ hóa snapshot mất từ 1 đến 3 ngày trên phần cứng được khuyến nghị. Đồng bộ hóa từ genesis mất nhiều thời gian hơn đáng kể và không được khuyến khích.

Phần cứng vật lý (bare metal) thường tốn từ $500 đến $1,500 mỗi tháng tùy thuộc vào thông số kỹ thuật và vị trí địa lý của trung tâm dữ liệu. Các dịch vụ đám mây tương đương tốn kém hơn do chi phí ảo hóa trên các khối lượng công việc đòi hỏi lưu trữ cao. Sự tăng trưởng lưu trữ từ 100 đến 200 GB mỗi ngày buộc bạn phải lựa chọn giữa việc phân bổ trước các khối lượng lưu trữ khổng lồ hoặc tự động hóa việc cắt tỉa sổ cái.

Đối với các nhóm đang đánh giá quyết định giữa việc tự xây dựng hay đi mua, hãy so sánh chi phí của nhà cung cấp được quản lý trong phần so sánh nhà cung cấp trước khi cam kết mua sắm phần cứng.

Các Lỗi Solana RPC Thường gặp và Cách Khắc phục

429 Too Many Requests

Ứng dụng của bạn đã vượt quá giới hạn tốc độ (rate limit) trên mỗi IP của điểm cuối (endpoint) công cộng Solana. Để khắc phục:

1. Chuyển sang nhà cung cấp dịch vụ riêng được quản lý. Helius, QuickNode, Alchemy và Triton One cung cấp các gói dịch vụ phù hợp cho lưu lượng truy cập thực tế. Xem so sánh các nhà cung cấp RPC Solana riêng.
2. Triển khai exponential backoff (thử lại theo cấp số nhân). Khi nhận phản hồi 429, hãy thử lại với độ trễ tăng gấp đôi sau mỗi lần thử. Ví dụ mã nguồn nằm trong phần xử lý giới hạn tốc độ.
3. Gộp các yêu cầu đọc tài khoản với getMultipleAccounts. Lấy dữ liệu của 20 tài khoản trong một lần gọi chỉ tiêu tốn một yêu cầu thay vì 20.

Hết thời gian xác nhận giao dịch (Transaction Confirmation Timeouts)

Giao dịch được gửi qua sendTransaction không thành công. Blockhash có thể đã hết hạn hoặc mạng có thể đang bị tắc nghẽn. Để khắc phục:

1. Gọi getLatestBlockhash ngay trước khi xây dựng giao dịch. Không sử dụng getRecentBlockhash (đã bị loại bỏ).
2. Kiểm tra lastValidBlockHeight từ phản hồi và thử lại trước khi đạt đến chiều cao khối đó.
3. Sử dụng sendAndConfirmTransaction thay vì sendTransaction thô để tự động thử lại khi gặp lỗi tạm thời.

Lỗi giới hạn tốc độ getProgramAccounts

getProgramAccounts là một trong những lệnh gọi RPC tiêu tốn nhiều tài nguyên nhất. Các điểm cuối công cộng thường hạn chế hoặc từ chối hoàn toàn do tải trọng nó đặt lên cơ sở hạ tầng chung. Nếu bạn thấy lỗi 403 hoặc lỗi hết thời gian (timeout) cụ thể ở các lệnh gọi này, hãy nâng cấp lên nhà cung cấp RPC riêng có hỗ trợ rõ ràng cho các truy vấn tài khoản chương trình lớn.

Câu hỏi thường gặp: Các nút (Node) RPC Solana

Nút RPC Solana là gì?

Nút RPC Solana là một máy chủ triển khai JSON-RPC API của Solana, chấp nhận các yêu cầu từ ứng dụng khách và trả về dữ liệu trạng thái của Blockchain. Các dApp, ví và trình khám phá khối sử dụng chúng để đọc số dư tài khoản, lấy lịch sử giao dịch và gửi các giao dịch đã ký lên mạng mà không cần chạy một bản sao sổ cái tại địa phương.

Sự khác biệt giữa nút RPC Solana và nút validator là gì?

Hai loại nút này phục vụ các vai trò khác nhau. Nút RPC cung cấp dữ liệu cho các máy khách bên ngoài thông qua JSON-RPC API, không tham gia vào quá trình đồng thuận và không nhận được phần thưởng Staking. Nút validator bỏ phiếu cho tính hợp lệ của khối trong mỗi khe (slot), yêu cầu SOL được Staking và nhận phần thưởng SOL cho các phiếu bầu chính xác. Một số đơn vị vận hành cả hai trên cùng một phần cứng, nhưng các vai trò vẫn tách biệt về mặt logic.

Điểm cuối RPC công cộng của Solana có miễn phí không?

Có. Các điểm cuối công cộng của Solana Foundation tại api.mainnet-beta.solana.com, api.devnet.solana.com và api.testnet.solana.com là miễn phí. Chúng áp đặt giới hạn tốc độ khoảng 100 yêu cầu trong mỗi khoảng thời gian 10 giây cho mỗi địa chỉ IP. Các điểm cuối này đủ dùng cho việc phát triển và thử nghiệm nhưng không phù hợp cho các dApp thực tế phục vụ người dùng thật.

Ba cách tiếp cận kết hợp với nhau: chuyển sang nhà cung cấp RPC riêng được quản lý cho lưu lượng truy cập thực tế; triển khai exponential backoff để thử lại các yêu cầu thất bại với khoảng thời gian chờ tăng dần; và gộp nhiều lần đọc tài khoản vào các lệnh gọi getMultipleAccounts duy nhất thay vì phát hành một lệnh getAccountInfo cho mỗi tài khoản.

Tối thiểu: CPU 12 nhân, RAM 256 GB DDR4, SSD NVMe 2 TB và kết nối mạng chuyên dụng 1 Gbps. Khuyến nghị cho thực tế: CPU 24 nhân, RAM 512 GB, 2 ổ SSD NVMe 2 TB và mạng 10 Gbps. Xác minh các thông số kỹ thuật hiện tại theo tài liệu validator Solana,) vì các yêu cầu sẽ tăng lên khi mạng lưới phát triển.

Dự kiến mất từ 1 đến 3 ngày nếu sử dụng snapshot (ảnh chụp nhanh) gần đây trên phần cứng được khuyến nghị. Đồng bộ hóa từ khối khởi thủy (genesis) sẽ mất nhiều thời gian hơn đáng kể. Solana Foundation cung cấp các snapshot chính thức để tăng tốc quá trình này.

HTTP RPC sử dụng mô hình yêu cầu-phản hồi phi trạng thái (stateless). Ứng dụng của bạn gửi một yêu cầu và nhận một phản hồi, hoạt động tốt cho các truy vấn một lần như getBalance hoặc sendTransaction. WebSocket RPC sử dụng kết nối liên tục với mô hình đăng ký (subscription). Ứng dụng của bạn đăng ký các sự kiện Trên chuỗi và nhận thông báo đẩy khi các sự kiện đó xảy ra. Sử dụng WebSocket cho bất kỳ tính năng thời gian thực nào trong dApp của bạn.

Helius và QuickNode là hai lựa chọn thường xuyên được thảo luận, nhưng sự phổ biến trong cộng đồng không phải là bằng chứng cho sự phù hợp hoặc hiệu suất. Helius phù hợp với các nhóm xây dựng độc quyền trên Solana, những người cần các API nâng cao gốc Solana. QuickNode phù hợp với các nhóm hỗ trợ nhiều Blockchain dưới một tài khoản. Triton One là lựa chọn cho các khối lượng công việc cấp tổ chức, nơi độ trễ p99 là yếu tố hạn chế chính. Lựa chọn đúng đắn tùy thuộc vào khối lượng công việc của bạn và việc các tính năng đặc thù của Solana hay hỗ trợ đa chuỗi quan trọng hơn.

Hướng dẫn Solana liên quan

• Giải thích về truyền bá khối Solana Turbine
• Giải thích về slot và thời gian khối 400ms của Solana

Khám phá SOL trên Bybit

Người đọc có thể xem lại thông tin thị trường SOL hiện tại) hoặc thị trường Giao ngay SOL/USDT.). Các liên kết này cung cấp thông tin thị trường và quyền truy cập; chúng không xác thực một tuyên bố kỹ thuật hoặc ngụ ý rằng SOL phù hợp với mọi người đọc.

Chọn chiến lược RPC Solana phù hợp cho trường hợp sử dụng của bạn

Có ba lộ trình và hầu hết các nhóm sẽ nhận ra lộ trình nào phù hợp với giai đoạn hiện tại của họ ngay lập tức.

Độ tin cậy của RPC ảnh hưởng đến việc đọc ứng dụng và gửi giao dịch, nhưng thời lượng slot mục tiêu không phải là một sự đảm bảo xác nhận và độ trễ RPC chỉ là một yếu tố ảnh hưởng đến việc giao dịch có thành công hay không. Hãy chọn cấp độ phù hợp với quy mô hiện tại của bạn và lên kế hoạch nâng cấp trước khi giới hạn tốc độ trở thành vấn đề đối với người dùng.

Các bước tiếp theo:

• Đăng ký gói phát triển miễn phí: helius.dev hoặc quicknode.com
• Xem lại tài liệu tham khảo đầy đủ về phương thức Solana JSON-RPC: docs.solana.com/api
• Xem lại thông số kỹ thuật phần cứng trước khi chuẩn bị tự vận hành: Cách chạy nút RPC Solana của riêng bạn