ERPC

FAQ - Direct Shreds

H. Output Shreds / getBlock của tôi đột nhiên bị lỗi hoặc trả về -32015 — điều gì đã thay đổi?

Solana Transaction v1 (SIMD-0385) đã có hiệu lực trên mainnet Solana vào ngày 15 tháng 9 năm 2026, tại epoch 1035. Wire layout của một transaction v1 bắt đầu bằng byte tiền tố phiên bản 0x81, chữ ký nằm sau message, và không còn tiền tố độ dài legacy nữa.
Nếu bạn tự giải mã các entry của ShredStream, Direct Shreds hoặc UDP Forwarding, decoder bincode hoặc solana-entry dưới phiên bản 4.2 sẽ đọc nhầm byte 0x81 đó thành số lượng chữ ký, biểu hiện là lỗi EOF, tràn compact-length, hoặc lỗi "invalid message version". Người dùng Geyser gRPC deserialize raw transaction bằng các crate trước 4.2 cũng gặp vấn đề tương tự. Các lời gọi RPC getBlock và getTransaction với maxSupportedTransactionVersion: 0 sẽ trả về -32015 Transaction version (1) is not supported by the requesting client; getTransactionsForAddress ở chế độ full báo cùng lỗi đó trên từng dòng bị ảnh hưởng. Bạn không bị ảnh hưởng nếu đã đọc các response JSON đã parse của ERPC với version 1 được đặt sẵn.
Đặt maxSupportedTransactionVersion thành 1 trong options object — tham số thứ hai của getBlock và getTransaction, và cả trong options của getTransactionsForAddress:
json
{
  "maxSupportedTransactionVersion": 1
}
Nâng cấp Solana Stream SDK lên 2.0.0: solana-stream-sdk cho Rust trên crates.io, hoặc @validators-dao/solana-stream-sdk và @validators-dao/solana-shreds-client trên npm. Nâng cấp riêng @validators-dao/solana-entry-decoder lên 2.5.0. 1.4.0 và entry-decoder 2.4.0 không hỗ trợ v1. Decoder Rust tự viết nên chuyển sang solana-entry 4.2.x.

H. Các node của bạn nằm ở khu vực nào?

Chúng tôi hiện vận hành node tại các khu vực sau:
  • Frankfurt (FRA)
  • Amsterdam (AMS)
  • London (LON)
  • Dublin (DUB)
  • New York (NY)
  • Chicago (CHI)
  • Salt Lake City (SLC)
  • Tokyo (TY)
  • Singapore (SGP)
  • Sydney (SYD)
ERPC đo độ trễ mạng thực tế dựa trên đường định tuyến thực, tự động chọn khu vực có độ trễ thấp nhất thay vì dựa vào khoảng cách đường thẳng. Cách tiếp cận này không chỉ cải thiện độ trễ cho từng người dùng mà còn nâng cao hiệu quả mạng tổng thể và tăng cường khả năng chống chịu toàn cầu của ERPC trước các cuộc tấn công tiềm ẩn.
Nếu môi trường của bạn không tự động chọn khu vực tối ưu, vui lòng liên hệ với chúng tôi qua ERPC Web Dashboard.
ERPC Web Dashboard: https://dashboard.erpc.global/vi

H. Độ trễ hiển thị 9999ms và khu vực không tối ưu được chọn. Tôi nên làm gì?

Để chọn khu vực cho Shreds, ERPC gửi các gói thăm dò độ trễ ICMP đến IP đã đăng ký của bạn từ các máy chủ proxy được liệt kê bên dưới. Hãy cho phép các yêu cầu ICMP echo đến từ mọi IP nguồn được liệt kê. Nếu bị tường lửa (ufw, tường lửa đám mây, nhóm bảo mật, v.v.) chặn, kết quả đo có thể trở thành 9999ms và một khu vực không tối ưu có thể được chọn. Nhiều IP trong cùng một khu vực là các máy chủ thăm dò riêng biệt; tất cả đều bắt buộc.
Khu vựcIP nguồn ICMP
🇳🇱 Amsterdam82.21.43.35
🇺🇸 New York151.243.244.162
🇩🇪 Frankfurt151.241.178.73
🇯🇵 Tokyo143.20.238.88
🇸🇬 Singapore151.245.186.3
🇬🇧 London151.241.65.10

Đã chọn Far Point

Far Point của Shared Shreds là phương án dự phòng có dung lượng giới hạn. Mỗi endpoint hỗ trợ tổng cộng tối đa 32 luồng được proxy đồng thời cho tất cả khách hàng—không phải 32 vị trí cho mỗi khách hàng. Truyền phát đạt hiệu quả cao nhất khi subscriber chạy gần endpoint Shreds đã chọn; các luồng đường dài duy trì kết nối dùng chung, cửa sổ điều khiển luồng và dung lượng egress lâu hơn. Để góp phần duy trì khả năng phản hồi của môi trường dùng chung, hãy cho phép tất cả địa chỉ IP nguồn của các probe ICMP theo khu vực được liệt kê và chạy lại quá trình chọn khu vực. Để sử dụng lâu dài, hãy cân nhắc một ERPC VPS gần endpoint đã chọn. Với UDP Forwarding Standard, hãy chọn một khu vực khả dụng trong quá trình cấu hình ban đầu và cấu hình địa chỉ IPv4 công cộng hợp lệ, không trống cùng cổng làm đích. Khu vực và đích có thể được thay đổi sau trong dashboard. Việc đổi khu vực làm thay đổi IP nguồn của quá trình chuyển tiếp, vì vậy tường lửa ở phía nhận cần cho phép IP nguồn mới của quá trình chuyển tiếp.
Sử dụng ERPC VPS gần endpoint này · Định cấu hình UDP Forwarding Standard Đọc hướng dẫn nhanh Direct Shreds

H. Tôi đã allowlist IP nhưng vẫn không kết nối được. Cần kiểm tra gì?

Các endpoint gRPC và Shreds của ERPC dùng HTTP thường trên port 80, được bảo vệ bằng IP allowlisting. Chúng không dùng HTTPS/TLS trên port 443.
Nếu bạn sao chép ví dụ client từ nhà cung cấp khác, ví dụ đó có thể mặc định dùng :443 hoặc HTTPS. Nếu chỉ thay domain, port và cấu hình TLS có thể vẫn giữ nguyên, khiến kết nối không hoạt động.
Các endpoint bên dưới chỉ là ví dụ. Hãy thay bằng endpoint của bạn hiển thị trong dashboard. Dùng endpoint đó ở dạng HTTP, hoặc chỉ rõ port 80 nếu client yêu cầu host và port:
  • Không hợp lệ: shreds-fra6-1.erpc.global:443
  • Hợp lệ: shreds-fra6-1.erpc.global:80
  • Dạng URL hợp lệ: http://shreds-fra6-1.erpc.global
Việc xác thực dựa trên địa chỉ IP đã đăng ký của bạn. Không thêm các header x-token, token hoặc Authorization cho endpoint gRPC hoặc Shreds của ERPC, trừ khi một trang sản phẩm cụ thể yêu cầu rõ ràng.

H. Tôi chỉ mới sử dụng WebSocket hoặc Geyser gRPC (YellowStone). Bạn có mẫu không?

Có. Bạn có thể nhanh chóng bắt đầu kiểm tra kết nối Shreds và phát triển ứng dụng bằng SLV.
Vui lòng tham khảo hướng dẫn sau:

H. Tôi có thể đăng ký hai địa chỉ IP không?

Bạn có thể sử dụng một endpoint cho mỗi gói đăng ký. Nếu bạn muốn sử dụng hai địa chỉ IP, bạn phải đăng ký hai gói đăng ký riêng biệt.

H. Bạn khuyến nghị khu vực nào?

Không có một khu vực tốt nhất cố định. Solana là mạng toàn cầu, và vai trò leader luân phiên giữa các validator, hết slot này đến slot khác. Khu vực có nhiều validator và stake lớn sẽ xuất hiện leader slots thường xuyên hơn, điều này có thể giúp giao dịch có lợi thế về thời gian landing. Đổi lại, lưu lượng cạnh tranh cũng tập trung ở đó, nên tùy chiến lược, một khu vực ít đông đúc hơn đôi khi có thể cho kết quả tốt hơn.
Để khởi đầu một cách thực tế, hãy chọn khu vực dày đặc validator như Frankfurt hoặc bờ Đông Hoa Kỳ khi nguồn leader slots ổn định là yếu tố quan trọng nhất, hoặc đặt hạ tầng gần một target validator cụ thể khi ưu tiên thực thi theo đường đi ngắn nhất. Hãy dùng Validators Solutions để hiểu phân bố công khai của mạng Solana, sau đó dùng ERPC Leader Slot API và đo đạc thực tế để quyết định single-region, dual-region, hay global deployment phù hợp.
Solana Mainnet Distribution Report

H. Tôi cần độ trễ ít nhất khoảng 400ms hoặc tốt hơn.

Để đạt độ trễ trong khoảng 400ms, hãy xem xét các điểm thiết yếu sau:
  • Hiểu thực tế về giá trị Ping: Giá trị ping cho biết điều kiện lý tưởng và không phản ánh độ trễ thực tế trong giao tiếp streaming, thường gấp khoảng 5 lần độ trễ ping. Ví dụ, ping 100ms xuyên lục địa thực tế dẫn đến khoảng 500ms độ trễ. Do đó, hạ tầng phải được thiết lập trong cùng khu vực để đạt độ trễ ~400ms.
    • Tham chiếu giá trị Ping điển hình:
      • Cùng mạng: ~0.1ms
      • Private Network Interconnect (PNI): ~0.2ms
      • Cùng data center: ~0.3ms
      • Cùng thành phố: ~1ms
      • Nước láng giềng: ~5–10ms
      • Xuyên lục địa: ~100–300ms
  • Tránh bẫy của độ trễ trung bình: Solana validator được phân tán trên toàn cầu, và lịch trình leader thay đổi ngẫu nhiên mỗi epoch. Dựa vào độ trễ trung bình để đạt ~400ms là không thực tế. Thay vào đó, bạn nên theo dõi chính xác lịch trình validator trong khu vực cụ thể của bạn để xác định slot có độ trễ thấp nhất. Để luôn đạt độ trễ tối thiểu, cần có hạ tầng tại tất cả các khu vực liên quan. Trong cùng khu vực, việc thu thập dữ liệu có thể diễn ra trong hàng chục mili giây, còn việc truyền dữ liệu có thể chỉ mất vài mili giây.
  • Theo dõi lịch trình Leader: Giám sát lịch trình validator leader cho khu vực của bạn bằng ERPC Leader Slot API (getLeaderSlots). API trả về lịch trình leader sắp tới, stake weight của epoch hiện tại, vị trí địa lý ước tính của validator và giá trị ping tham chiếu, nhờ đó bạn có thể xác định những slot có độ trễ thấp nhất để nhắm tới trước khi các slot đó diễn ra. Dữ liệu kiểu bản đồ công khai và các API RPC gốc hữu ích cho việc quan sát mạng ở phạm vi rộng, nhưng chúng không đủ chính xác cho việc canh thời điểm thực thi. Leader Slot API lấp đầy khoảng trống đó với độ chi tiết cần thiết cho các quyết định định tuyến và giao dịch.
Validators Solutions - dữ liệu mạng Solana
Dữ liệu mạng Solana: Validators Solutions

H. Làm thế nào để đạt giao dịch zero-block (zero-slot)?

Đạt được giao dịch zero-block (zero-slot) thành công đòi hỏi các chiến lược tinh vi hơn, như sau:
  • Xác định vùng cơ hội: Solana validator được phân tán trên toàn cầu, và về mặt vật lý không thể đạt độ trễ tối ưu cho mọi slot. Do đó, hãy giám sát lịch trình validator leader tại khu vực đặt hạ tầng của bạn và xác định các vùng cơ hội thuận lợi nhất. Triển khai hạ tầng trên nhiều khu vực cũng có thể có lợi. Ví dụ, Frankfurt là khu vực then chốt do mật độ validator cao, dẫn đến tần suất chọn leader cao hơn và nhiều cơ hội giao dịch hơn.
    Sử dụng ERPC Leader Slot API (getLeaderSlots) để tra cứu lịch trình leader sắp tới, stake weight của epoch hiện tại, dữ liệu vị trí địa lý ước tính của validator và giá trị ping tham chiếu, với độ chính xác cao hơn nhiều so với các nguồn dữ liệu dạng bản đồ công khai hoặc API RPC gốc. Nhờ đó, bạn có thể khoanh định các vùng cơ hội trước khi các slot diễn ra và thực hiện giao dịch với độ trễ gần như bằng không.
  • Triển khai Dedicated Node: Nếu bạn gặp khó khăn trong cạnh tranh, hãy cân nhắc triển khai dedicated node. Shared node gặp độ trễ do lưu lượng từ người dùng khác, và do đó không được khuyến nghị. Hơn nữa, đặt dedicated node trong cùng mạng với ứng dụng của bạn giúp giảm đáng kể độ trễ mạng và tối ưu hiệu suất.

H. Tôi có thể sử dụng endpoint cụ thể không?

Để duy trì môi trường độ trễ thấp, hệ thống tự động chọn node gần nhất khả dụng. Nếu bạn muốn sử dụng endpoint cụ thể, chúng tôi khuyến nghị thuê server đặt gần endpoint đó nhất.

H. Tại sao dedicated endpoint nhanh hơn?

Shared endpoint được sử dụng bởi nhiều khách hàng chia sẻ cùng tài nguyên. Khi lưu lượng tăng, độ trễ có xu hướng xảy ra. Tài nguyên server có giới hạn vật lý, và khối lượng công việc chúng có thể xử lý là hữu hạn. Khi quá nhiều request đến cùng lúc, chúng phải được xử lý tuần tự, dẫn đến thời gian phản hồi chậm hơn.
Mặc dù chúng tôi thực hiện nhiều biện pháp để tối ưu hiệu suất ngay cả trên shared endpoint, với dedicated endpoint bạn là người dùng duy nhất của tài nguyên. Điều này có nghĩa bạn hoàn toàn không bị ảnh hưởng bởi người dùng khác, đảm bảo phản hồi ổn định và nhanh nhất quán.
Ngoài ra, dedicated endpoint cung cấp tùy chọn giao tiếp không TLS, như HTTP. Bằng cách bỏ qua TLS handshake (khoảng 20ms), giao tiếp trở nên nhanh hơn so với HTTPS.

H. Giá khuyến mãi có tăng sau khi tôi đăng ký không?

Miễn là subscription của bạn vẫn hoạt động, mức giá khuyến mãi bạn đã khóa khi đăng ký sẽ tiếp tục được áp dụng. Môi trường đủ sức chịu workload real-time của Solana là tài nguyên khan hiếm trên toàn cầu, và chúng tôi dự kiến tăng dần giá niêm yết theo nhu cầu phần cứng và mạng. Cấu hình cao hơn và khu vực có nhu cầu lớn hết hàng nhanh nhất, nên khóa mức giá khuyến mãi hiện tại là lựa chọn tiết kiệm chi phí nhất về dài hạn.

H. Tôi muốn thanh toán bằng crypto

Thanh toán bằng crypto khả dụng trong ERPC Web Dashboard khi quốc gia trong địa chỉ thanh toán đã đăng ký của bạn là một trong các quốc gia thành viên EU. Bạn có thể dùng SOL, USDC hoặc EURC để mua ERPC Credits.
Dùng ERPC Credits đó để kích hoạt hoặc duy trì các gói ERPC. Mở dashboard, chọn Thanh toán crypto, chuyển tiền từ wallet của bạn, rồi dashboard sẽ xác minh giao dịch và cộng credit vào tài khoản của bạn.
Quốc gia được hỗ trợ: Áo, Ba Lan, Bỉ, Bồ Đào Nha, Bulgaria, Croatia, Đan Mạch, Đức, Estonia, Hà Lan, Hungary, Hy Lạp, Ireland, Italy, Latvia, Litva, Luxembourg, Malta, Pháp, Phần Lan, Romania, Séc, Síp, Slovakia, Slovenia, Tây Ban Nha, Thụy Điển.
Với các quốc gia không có trong danh sách, vui lòng thanh toán bằng thẻ tín dụng.
ERPC Web Dashboard

H. Tại sao ShredStream không bao gồm tất cả transaction?

Theo thiết kế, Shreds không bao gồm mọi transaction trên Solana blockchain. Giám sát tất cả transaction đòi hỏi triển khai nhiều proxy trên toàn cầu và nhận Shreds từ mọi validator, điều không thực tế.
Thông thường, người dùng hoạt động với một tập con dữ liệu có sẵn, vì cách tiếp cận này đủ cho hầu hết ứng dụng thực tế. Nếu trường hợp sử dụng của bạn đòi hỏi độ phủ dữ liệu hoàn toàn, không mất mát bất kỳ dữ liệu nào, Shreds có thể không phù hợp.
Với các tình huống cần giám sát toàn diện hơn, Geyser gRPC mang lại độ tin cậy cao hơn so với Shreds. Tuy nhiên, để đạt độ phủ dữ liệu 100% trên Solana blockchain vẫn cần triển khai rất nhiều edge server, điều này có thể không khả thi trên thực tế.
Geyser gRPC có độ tin cậy vượt 99%, cao hơn đáng kể so với Shreds, điều đã được nhiều người dùng, kể cả chúng tôi, xác nhận. Trong khi đó, Shreds thường đạt độ tin cậy trên 90%.
Dù không thu được mọi transaction, ưu điểm chính của Shreds là khả năng nhận phần lớn transaction nhanh hơn Geyser gRPC.
Để hiểu sâu hơn, chúng tôi khuyến nghị khám phá giao thức Turbine và Gulf Stream của Solana:

H. Tôi muốn môi trường tốt nhất có thể.

Với UDP Forwarding Standard, hãy chọn một khu vực khả dụng trong quá trình thiết lập ban đầu và cấu hình địa chỉ IPv4 công khai hợp lệ, không trống cùng cổng làm đích. Khu vực và đích có thể được thay đổi sau trong dashboard. Việc đổi khu vực làm thay đổi IP nguồn của quá trình chuyển tiếp, vì vậy tường lửa ở phía nhận cần cho phép IP nguồn mới của quá trình chuyển tiếp.
Vui lòng liên hệ với chúng tôi qua ERPC Web Dashboard để biết thêm chi tiết.
ERPC Web Dashboard
🔗 ERPC Web Dashboard

H. Độ trễ như thế nào?

Độ trễ thay đổi tùy thuộc vào phương pháp đo và môi trường sử dụng cụ thể của bạn. Thay vì tập trung vào giá trị số chính xác, điều quan trọng là đảm bảo độ trễ đáp ứng yêu cầu vận hành thực tế.
Chúng tôi cung cấp công cụ dễ sử dụng bằng TypeScript và Rust để đo độ trễ.

H. RPC (gRPC, Shreds) này có nhanh hơn các dịch vụ khác không?

Chúng tôi thiết kế mọi gói dịch vụ với ưu tiên tốc độ, và sẵn lòng để điều đó được đo song song với bất kỳ nhà cung cấp nào khác. Kết quả thay đổi theo khu vực, theo việc bạn dùng shared endpoint hay dedicated endpoint, theo giao thức (WebSocket, gRPC hoặc Shreds) và theo ngôn ngữ lập trình của client.
Nếu bạn thấy dịch vụ của chúng tôi chậm hơn, vui lòng cho chúng tôi biết qua ERPC Web Dashboard về điều kiện cụ thể và các đối thủ mà bạn đã dùng để so sánh. Chúng tôi sẽ xác định nguyên nhân và cải thiện tốc độ hơn nữa.
ERPC Web Dashboard

H. Gói nào cung cấp hiệu suất nhanh nhất?

Nói chung, gói cao cấp nhất cung cấp hiệu suất nhanh nhất nhờ CPU vượt trội, dung lượng bộ nhớ cao hơn, và cấu hình phần cứng mạnh mẽ.
Chúng tôi cũng cung cấp giải pháp tùy chỉnh nếu bạn cần server mạnh hơn, nhưng các gói tiêu chuẩn được thiết kế để mang lại tỷ lệ giá-hiệu suất tối ưu.
Chúng tôi tự tin cung cấp hiệu suất đẳng cấp thế giới ở mọi mức giá. Nếu bạn tìm thấy nhà cung cấp nhanh hơn trong cùng phạm vi giá, vui lòng cho chúng tôi biết để điều tra và cải thiện.

H. Tôi gặp độ trễ cao. Tại sao?

Độ trễ tăng đáng kể theo khoảng cách đến endpoint. Chúng tôi khuyến nghị truy cập từ một server đặt gần hơn với endpoint được cung cấp. Môi trường nhanh nhất có sẵn qua Bare-Metal server và dịch vụ VPS của chúng tôi.

H. Cái nào nhanh nhất: WebSockets, gRPC, hay Shreds?

Dựa trên phản hồi của khách hàng, thứ tự hiệu suất như sau:
Shreds > gRPC > WebSockets
Nếu trải nghiệm của bạn khác, vui lòng cho chúng tôi biết.

H. Độ trễ không như tôi mong đợi.

Hiệu suất thay đổi đáng kể tùy theo ngôn ngữ lập trình được sử dụng. Nói chung, thứ tự hiệu suất như sau:
Rust > Go > TypeScript (JavaScript) > Python
Để xem so sánh chi tiết, vui lòng tham khảo:
So sánh tốc độ ngôn ngữ lập trình
Chúng tôi đặc biệt khuyến nghị Rust để đạt hiệu suất cao nhất.

Trước đó

Câu hỏi thường gặp về Solana RPC Endpoint | ERPC

Tiếp theo

FAQ - VPS