ERPC phát hành Solana Stream SDK v4.0.0, tăng tốc xử lý UDP Shreds và khôi phục kết nối gRPC

ERPC phát hành Solana Stream SDK v4.0.0, tăng tốc xử lý UDP Shreds và khôi phục kết nối gRPC

ERPC phát hành Solana Stream SDK v4.0.0, tăng tốc xử lý UDP Shreds và khôi phục kết nối gRPC
ELSOUL LABO B.V. và Validators DAO đã chính thức phát hành Solana Stream SDK v4.0.0, SDK mã nguồn mở để xử lý dữ liệu dạng luồng của Solana, vào ngày 6 tháng 11 năm 2026. Kết quả đo hiệu năng cục bộ cho thấy tốc độ xử lý nội bộ Rust UDP Shreds đạt khoảng 108 lần và thông lượng hàng đợi sự kiện TypeScript đạt khoảng 4 lần so với trước. Geyser gRPC cũng tiếp tục nhận bản cập nhật sớm hơn sau khi mất kết nối. SDK được cung cấp miễn phí, kèm các ví dụ Rust và TypeScript để giúp nhà phát triển bắt đầu.
Việc tận dụng khả năng truyền dữ liệu có độ trễ thấp trong ứng dụng còn phụ thuộc vào tốc độ xử lý dữ liệu đến. Phiên bản 4.0.0 nâng cao hiệu quả xử lý nội bộ sau khi dữ liệu đến và cải thiện khả năng khôi phục sau khi mất kết nối. Khi sử dụng cùng ERPC Shreds UDP Forwarding Premium, nhà phát triển có thể cải thiện cả đường truyền dữ liệu lẫn phần triển khai phía nhận cho ứng dụng Solana.

Đo lường cải thiện về xử lý và khôi phục qua ba bài kiểm thử

So sánh xử lý nội bộ Rust UDP, hàng đợi sự kiện TypeScript và khôi phục kết nối gRPC trong Solana Stream SDK v4.0.0
Trong đường xử lý nhận UDP của Rust, v4 tăng tốc việc giải mã datagram, chèn vào bộ đệm nội bộ và thực hiện deshred để tái dựng dữ liệu từ Shreds. Phiên bản này giảm chi phí xử lý bằng cách điều chỉnh việc dọn dẹp trạng thái nội bộ và đọc đồng hồ vốn được lặp lại cho mỗi gói tin, đồng thời vẫn giữ nguyên thời hạn lưu giữ dữ liệu. Trong phép so sánh, thời gian xử lý nội bộ cho mỗi datagram giảm từ 94,236 ns xuống 855–881 ns, tương ứng với tốc độ khoảng 108 lần so với trước.
Bài đo hiệu năng chạy trên máy Mac dùng chip Apple M-series, xử lý 403,200 datagram thuộc 300 slot trong mỗi lần chạy. Kết quả được so sánh bằng trung vị của năm lần chạy. Phạm vi đo là đường xử lý nội bộ decode→insert→deshred, không bao gồm thời gian truyền qua mạng hay phần xử lý tiếp theo trong ứng dụng của người dùng. Giảm khối lượng công việc cần thiết để tái dựng Shreds nhận được giúp nhà phát triển dành thêm tài nguyên tính toán cho logic ứng dụng.
Các ví dụ và dự án khởi đầu Geyser gRPC bằng TypeScript giảm thời gian chờ khi hàng đợi vẫn còn sự kiện, giúp truy xuất dữ liệu đã nhận một cách hiệu quả hơn. Trong bài kiểm thử riêng hàng đợi với hai triệu sự kiện trên Node.js 24, thông lượng tăng từ 5.7–7.4 triệu sự kiện mỗi giây lên 24.8–29.4 triệu sự kiện mỗi giây, đạt khoảng 4 lần so với trước.
Đối với Geyser gRPC, client phụ trách kết nối lại và khoảng thời gian chờ trước lần thử lại đầu tiên đã được cập nhật. Trong bài kiểm thử tạo ra 20 lần mất kết nối trên máy chủ tonic cục bộ, trung vị khoảng cách thời gian giữa các bản cập nhật nhận được ngay trước và sau mỗi lần mất kết nối giảm từ 552 ms với 3.0 runner xuống 103 ms với 4.0 runner. Phép đo này phản ánh khoảng thời gian cho đến khi tiếp tục nhận bản cập nhật trong môi trường kiểm thử cục bộ.
Ba kết quả này đến từ các bài kiểm thử có phạm vi và điều kiện khác nhau. Chúng lần lượt thể hiện mức cải thiện trong xử lý nội bộ Rust, hàng đợi sự kiện TypeScript và việc kết nối lại gRPC. Chi tiết triển khai và điều kiện kiểm thử được công bố trong PR #129 ở phần Liên kết liên quan.

Duy trì hỗ trợ Alpenglow và cập nhật client

Hỗ trợ Alpenglow đã được đưa vào từ v3.0.0. Phiên bản 4.0.0 tiếp tục phân biệt giữa các dấu mốc khối, biểu thị cập nhật về header, footer và khối cha, với các entries chứa giao dịch. Ứng dụng có thể xử lý thông tin về cấu trúc khối riêng biệt với các entries cần xử lý.
Phiên bản 4.0.0 cập nhật client lên Agave 4.4.1 và Yellowstone gRPC 17.x. Trong quá trình kết nối lại, sự kiện Disconnected có thể báo thông tin giúp xác định dữ liệu mới chỉ nhận được một phần, cùng với vị trí tiếp tục nhận. Nhờ đó, ứng dụng có đủ thông tin để tự triển khai cách xử lý dữ liệu phát lại bị trùng và dữ liệu mới chỉ nhận được một phần.
Khi chuyển từ v3 sang v4, các định nghĩa protobuf của Geyser được giữ nguyên, còn sự kiện kết nối lại cùng các kiểu Solana message và transaction dùng trong Rust được cập nhật. Hướng dẫn chuyển đổi đã công bố mô tả những thay đổi đối với bộ xử lý sự kiện và phiên bản của các thư viện phụ thuộc.

Dùng Rust cho UDP, hoặc Rust và TypeScript cho gRPC

Gói Rust solana-stream-sdk và gói TypeScript @validators-dao/solana-stream-sdk đã công bố đều có phiên bản v4.0.0. Các ngôn ngữ được hỗ trợ theo từng loại kết nối được liệt kê bên dưới.
Loại kết nốiNgôn ngữ được hỗ trợ
Shreds UDPRust
Geyser gRPCRust và TypeScript
Shreds gRPCRust và TypeScript
Hãy dùng client Rust để nhận Shreds qua UDP. Ví dụ và dự án khởi đầu Rust UDP sử dụng SDK v4.0.0 đã công bố, cho phép thử nhận dữ liệu, tái dựng dữ liệu từ Shreds và phát hiện các lệnh của chương trình cần theo dõi. Bạn có thể thay đổi chương trình được theo dõi và phần xử lý sau khi phát hiện để dùng đây làm điểm khởi đầu cho ứng dụng của mình.
Khi phát triển bằng TypeScript, bạn có thể sử dụng Geyser gRPC hoặc Shreds gRPC. Các cải thiện hàng đợi sự kiện trong bản phát hành này đã có trong các ví dụ và dự án khởi đầu Geyser gRPC. Hãy chọn phần triển khai đã công bố phù hợp với ngôn ngữ và phương thức truyền dữ liệu của bạn.

Tận dụng Shreds UDP Forwarding Premium

ERPC Shreds UDP Forwarding Premium kết nối nhiều nút thành một mạng lưới dạng mesh trong mỗi khu vực và chuyển tiếp bản sao đến sớm nhất của từng Shred mà mạng lưới này nhận được. Thời điểm dữ liệu đến qua đường truyền và thời gian tái dựng bên trong SDK sau khi dữ liệu đến đều ảnh hưởng đến thời điểm có thể sử dụng dữ liệu đã nhận. Các cải thiện trong quá trình nhận UDP bằng Rust có thể được áp dụng ở phía nhận để xử lý dữ liệu do Premium truyền đến.
Trong phép so sánh tại Frankfurt ngày 30 tháng 10 năm 2026, dữ liệu Standard và Premium được thu thập đồng thời trong 120 giây trên cùng một máy và sử dụng cùng một đồng hồ. Các payload UDP có nội dung giống nhau được đối sánh từ pcap. Trong tập dữ liệu đã đối sánh này, Premium đến trước ở 98% trường hợp, với trung vị chênh lệch thời gian đến là 1.78 ms. Trong số các payload quan sát được trên Standard, 93.9% cũng được quan sát thấy trên Premium.
So sánh khả năng đến trước giữa Shreds UDP Forwarding Premium và Standard trong cùng điều kiện tại Frankfurt
Biểu đồ Premium thể hiện chênh lệch thời gian đến giữa các đường truyền, còn biểu đồ SDK thể hiện xử lý nội bộ phía nhận và việc khôi phục kết nối. Trong ứng dụng thực tế, ghi lại cả thời điểm gói tin đến và thời điểm phát hiện lệnh liên quan sẽ giúp bạn xác định lợi thế về thời gian truyền được duy trì đến kết quả xử lý ở mức nào.

So sánh trong môi trường của bạn bằng dịch vụ tính phí theo giờ và các ví dụ

Shreds UDP Forwarding Premium có hình thức tính phí theo giờ với mức €1.39 mỗi giờ. Bạn có thể bắt đầu sử dụng dịch vụ từ bảng điều khiển và xác minh việc nhận dữ liệu bằng dự án khởi đầu Rust UDP. Giữ nguyên khu vực, máy chủ nhận và khối lượng công việc của ứng dụng cho phép đánh giá riêng chênh lệch thời gian đến và thời gian xử lý sau khi nhận.
Trước tiên, hãy đăng ký địa chỉ IPv4 công khai và cổng UDP trong bảng điều khiển, đồng thời cho phép lưu lượng đi vào từ các nguồn được liệt kê. Sau khi kiểm tra việc nhận gói tin và tái dựng dữ liệu bằng dự án khởi đầu Rust UDP, hãy đưa các chương trình cần theo dõi cùng phần xử lý thực tế của ứng dụng vào quá trình đánh giá. Kết hợp các ví dụ với dịch vụ truyền dữ liệu để đo thời gian từ lúc nhận đến lúc phát hiện trong môi trường của chính bạn.

Liên kết liên quan