ERPC mở rộng Solana Leader Slot API với phép đo ping từ 7 khu vực toàn cầu — Validators Information API cũng chính thức ra mắt
ELSOUL LABO B.V. (Trụ sở: Amsterdam, Hà Lan; Giám đốc Đại diện kiêm CEO: Fumitake Kawasaki) và Validators DAO, đơn vị vận hành ERPC, đã nâng cấp các API dùng để nắm bắt thông tin leader, vị trí ước tính và độ trễ của Solana, bổ sung hỗ trợ RTT tham chiếu (phép đo ping) từ 7 khu vực toàn cầu cho Leader Slot API và ra mắt Validators Information API mới.
Trước hết, chúng tôi đã mở rộng Leader Slot API (
getLeaderSlots) để có thể lấy RTT tham chiếu từ 7 khu vực quan trắc của ERPC trên toàn thế giới (Frankfurt, Amsterdam, New York, London, Tokyo, Singapore và Sydney). Trước đây, phép đo chỉ được thực hiện từ Frankfurt.Đồng thời, chúng tôi đã ra mắt Validators Information API mới (
getValidatorsInformation). Chỉ trong một lần gọi, API liệt kê mọi validator được phân công ít nhất một leader slot trong epoch hiện tại. Ngoài số slot và lượng stake đang hoạt động, API còn trả về — khi có dữ liệu — vị trí ước tính, endpoint mạng, phiên bản client và RTT tham chiếu từ 7 khu vực.Cả hai API đều có sẵn cho mọi người dùng ERPC thông qua giao diện JSON-RPC tiêu chuẩn.
- Tài liệu Leader Slot API: https://erpc.global/vi/doc/rpc/leader-slot-api/
- Tài liệu Validators Information API: https://erpc.global/vi/doc/rpc/validators-information-api/
Khác biệt với hạ tầng giao dịch truyền thống: đích liên lạc trên Solana thay đổi liên tục
Trong các sàn giao dịch và hệ thống tài chính truyền thống, đích gửi lệnh — sàn giao dịch, cổng kết nối, công cụ khớp lệnh — thường được cố định tại một trung tâm dữ liệu hoặc mạng lưới cụ thể.
Vì vậy, một khi đã biết đích kết nối, người dùng có thể liên tục tối ưu đường truyền mạng tới đích đó. Vì vị trí của các máy chủ đích không thay đổi thường xuyên, việc bố trí hạ tầng và tuyến liên lạc có thể được thiết kế tương đối cố định.
Ngược lại, trên Solana, leader — validator chịu trách nhiệm tạo block — luân chuyển sau mỗi vài slot theo leader schedule. Vì các validator đảm nhiệm vai trò leader phân tán khắp thế giới, cả đích mà giao dịch cần đến lẫn đường truyền mạng gần nhất tới đích đó đều thay đổi liên tục.
Nói cách khác, trên Solana, đích liên lạc cần tối ưu không thể được xem như một điểm kết nối duy nhất, cố định.
Trước tiên, bạn cần xác định leader hiện tại và tương lai từ leader schedule. Trên cơ sở đó, hãy kiểm tra từng validator có khả năng nằm ở khu vực hay mạng lưới nào, cũng như độ trễ từ từng vị trí gửi, rồi quyết định tuyến gửi.
Hiểu đúng cấu trúc này là điểm khởi đầu cho việc gửi giao dịch độ trễ thấp và thiết kế hạ tầng toàn cầu trên Solana.
Xử lý leader schedule và vị trí mạng như dữ liệu
Trong môi trường đích liên lạc thay đổi liên tục, việc con người mỗi lần lại kiểm tra leader và vị trí gửi rồi chuyển tuyến thủ công là không thực tế.
Điều cần thiết là liên tục thu thập các thông tin sau và đưa vào logic quyết định của ứng dụng và hạ tầng.
- Các leader phụ trách slot hiện tại và sắp tới
- Số lượng slot mỗi validator phụ trách
- Quốc gia, thành phố và khu vực ước tính của từng validator
- Các endpoint mạng như TPU và QUIC
- RTT tham chiếu thu thập từ từng khu vực quan trắc
- Thời điểm thu thập từng phép đo và trạng thái phản hồi
Vị trí ước tính và độ trễ đo được đóng vai trò khác nhau.
Thông tin vị trí có thể dùng cho các quyết định trung và dài hạn về việc đặt hạ tầng và năng lực ở đâu. Ngược lại, RTT tham chiếu từ từng khu vực là đầu vào để đánh giá hiện tại từ vị trí nào có khả năng tiếp cận bằng đường truyền ngắn.
Vị trí gần về mặt vật lý hay địa lý không phải lúc nào cũng là đường truyền ngắn nhất trên mạng. Vì vậy, điều quan trọng là kết hợp vị trí ước tính với các giá trị quan trắc thực tế để ra quyết định.
Leader Slot API và Validators Information API của ERPC là các API giúp bạn lập trình hóa các quyết định này dựa trên dữ liệu.
Leader Slot API: đo RTT tham chiếu từ 7 khu vực toàn cầu
Leader Slot API trả về các leader slot sắp tới, kèm danh tính validator, lượng stake đang hoạt động, endpoint mạng, vị trí ước tính, RTT tham chiếu và những thông tin khác.
Trước đây, các phép đo
pingToLeaders chỉ được thu thập từ điểm đo Frankfurt — một điểm quan sát duy nhất đối với mạng Solana phân tán toàn cầu.Với bản cập nhật này, giờ đây bạn có thể lấy RTT tham chiếu đo từ 7 khu vực sau.
frankfurtamsterdamnylondontokyosingaporesydney
Bằng cách so sánh RTT tham chiếu từ 7 khu vực quan trắc cho mỗi leader, bạn có thể đánh giá vị trí gửi nào có nhiều khả năng mang lại đường truyền mạng ngắn.
Đây là đầu vào ra quyết định không chỉ cho định tuyến giao dịch, mà còn cho việc quyết định bố trí năng lực cho RPC, gRPC, Direct Shreds, máy chủ gửi giao dịch và các dịch vụ khác ở những khu vực nào.
Kết quả đo bao gồm
icmpReplied, cho biết validator có phản hồi ICMP hay không, và measuredAt, cho biết thời điểm thu được phép đo thành công gần nhất.Một validator không phản hồi ICMP vẫn có thể đang vận hành bình thường các dịch vụ như TPU và QUIC. Vì vậy, khi
icmpReplied là false, cần hiểu đó không phải là "ở xa" mà là "không đo được qua ICMP".Ngoài ra, khi không thu được phép đo thành công tại thời điểm làm mới, mục đó sẽ không bị ghi đè bằng giá trị chưa đo — giá trị đo thành công gần nhất cùng thời điểm đo của nó được giữ nguyên.
Validators Information API: liệt kê thông tin leader trên toàn bộ epoch
Leader Slot API phù hợp với các quyết định ở cấp slot — "ai là leader phụ trách các slot tiếp theo?"
Ngược lại, bố trí hạ tầng và lập kế hoạch năng lực đòi hỏi góc nhìn rộng hơn.
- Các validator nào đang đảm nhiệm vai trò leader trong epoch hiện tại
- Mỗi validator phụ trách bao nhiêu slot
- Họ phân tán ở những quốc gia và khu vực nào
- Nên đặt hạ tầng ở khu vực nào để ở gần nhiều leader hơn
Validators Information API mới (
getValidatorsInformation) là API được xây dựng để trả lời những câu hỏi này.Khi được gọi không kèm tham số, API trả về mọi validator đảm nhiệm vai trò leader cho ít nhất một slot trong epoch hiện tại, mỗi validator một hàng. Theo mặc định, kết quả được sắp xếp giảm dần theo số leader slot mà validator nắm giữ.
Mỗi hàng bao gồm các thông tin sau.
slotCountstakeWeight(lượng stake đang hoạt động, tính bằng SOL)- Danh tính validator
Khi có sẵn, các thông tin sau cũng được trả về.
- Khu vực, thành phố và quốc gia ước tính
- Endpoint mạng
- Phiên bản client
- RTT tham chiếu từ 7 khu vực
Vì dữ liệu được làm mới định kỳ, việc gọi API thường xuyên giúp bộ dữ liệu lập kế hoạch của bạn luôn cập nhật.
Bạn cũng có thể thu hẹp kết quả bằng các tham số tùy chọn
limit (1–2000), country và region.Phí được tính theo số validator trả về. Số leader validator thay đổi qua từng epoch; trong ví dụ tại thời điểm viết bài, lấy đủ 673 validator sử dụng 6,800 API tokens (đơn vị sử dụng API của ERPC), còn lấy tối đa 10 validator sử dụng 100 API tokens.
Hướng tới định tuyến có thể lập trình và dựa trên dữ liệu
Các API này không đơn thuần để hiển thị danh sách validator hay RTT tham chiếu.
Mục tiêu cuối cùng là cho phép bạn đưa leader schedule, vị trí ước tính của các validator và RTT tham chiếu từ từng khu vực quan trắc vào logic quyết định của ứng dụng.
Ví dụ, một ứng dụng có thể lấy leader schedule sắp tới, so sánh RTT tham chiếu từ 7 khu vực quan trắc cho từng leader, rồi chọn RPC hoặc tuyến gửi giao dịch sẽ sử dụng.
Bạn cũng có thể phân tích phân bố leader trên toàn bộ epoch và đặt trước hạ tầng tại các khu vực gần những validator có số slot phụ trách cao.
Các trường hợp sử dụng điển hình như sau.
- Chọn tuyến gửi ở cấp slot
- Lập kế hoạch năng lực ở cấp epoch
- Phân tích leader validator theo khu vực
- Ưu tiên có tính đến lượng stake đang hoạt động và số slot phụ trách
- Giám sát thay đổi phân bố địa lý và mạng lưới qua từng epoch
- Tự động chọn giữa các RPC và máy chủ gửi được triển khai trên nhiều khu vực
Trên Solana, nơi đích liên lạc thay đổi liên tục, chỉ tối ưu mạng tĩnh thôi là chưa đủ.
Điều quan trọng là liên tục theo dõi leader luân chuyển và tự động chọn tuyến gửi cùng hạ tầng theo vị trí và tình trạng mạng của leader đó.
Hướng tới hạ tầng Solana được thiết kế cho vận hành toàn cầu
ERPC là hạ tầng hiệu năng cao dành cho Solana, được thiết kế ngay từ ngày đầu với tiền đề vận hành toàn cầu.
Mạng edge, máy chủ bare metal và VPS, Direct Shreds, Geyser gRPC, các endpoint SWQoS cùng những API thông tin vận hành này đều phục vụ một mục đích chung.
Mục đích đó là cung cấp cả dữ liệu lẫn hạ tầng cho những nhà phát triển cần khả năng thực thi hiệu quả với độ trễ thấp, trong một môi trường nơi người dùng và leader phân tán khắp thế giới.
RTT tham chiếu từ 7 khu vực toàn cầu và thông tin validator phủ khắp epoch nay đã có thể lấy qua các lệnh gọi RPC đơn giản. Các ứng dụng Solana nay có thể chọn vị trí gửi và tuyến mạng dựa trên dữ liệu để thích ứng với leader liên tục thay đổi.
Với những nhà phát triển cần gửi giao dịch với độ trễ thấp, bố trí hạ tầng toàn cầu và tối ưu định tuyến linh hoạt trên Solana, đây là đầu vào ra quyết định gắn trực tiếp với vận hành thực tế.
Chúng tôi hy vọng các API này sẽ hỗ trợ việc chọn tuyến gửi có độ trễ thấp, thiết kế hạ tầng giảm các chặng truyền đường dài không cần thiết và lập kế hoạch bố trí năng lực toàn cầu.
Chi tiết, xem tài liệu:
- Leader Slot API: https://erpc.global/vi/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/vi/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/vi
