includeBam: false để chỉ nhận các xác nhận trước của Helius.
Điểm cuối
preconfSubscribe được cung cấp từ điểm cuối Gatekeeper của Helius:
wss://beta.helius-rpc.com/?api-key=<API_KEY>
beta đề cập đến quá trình triển khai Gatekeeper, không phải mức độ hoàn thiện của Preconfirmations — đây sẽ trở thành điểm cuối tiêu chuẩn khi lưu lượng được chuyển sang Gatekeeper.
Luồng không liên tục. Phạm vi bao phủ tăng theo tỷ lệ stake mạng
chuyển tiếp đến Helius hoặc chạy BAM, vì vậy có thể có các slot không có thông báo — hãy xử lý
các khoảng trống này một cách phù hợp. Xem Phạm vi bao phủ.
Xác thực
string
bắt buộc
Khóa API Helius của bạn, được truyền dưới dạng tham số truy vấn
api-key. Yêu cầu gói Professional trở lên.Nội dung yêu cầu
array
Không bắt buộc. Bỏ qua
params để nhận mọi giao dịch từ cả Helius và BAM. Để thu hẹp luồng, hãy truyền một đối tượng bộ lọc làm phần tử đầu tiên — quá trình lọc diễn ra ở phía máy chủ, nên bạn chỉ trả phí và nhận các giao dịch mình quan tâm.-32602 (tham số không hợp lệ).
Bộ lọc tài khoản khớp với nhiều dữ liệu hơn các khóa tài khoản tĩnh của giao dịch — Helius phân giải bảng tra cứu địa chỉ v0 ở phía máy chủ, vì vậy accountInclude, accountExclude và accountRequired cũng khớp với các tài khoản mà giao dịch tải qua ALT.
Mã khu vực
Đối với các xác nhận trước của Helius, khu vực là nơi Helius tiếp nhận giao dịch. Đối với các xác nhận trước của BAM, đó là điểm cuối BAM theo khu vực đã phát xác nhận trước, không phải nơi Helius tiếp nhận giao dịch. Các điểm cuối Singapore và Dallas của BAM ánh xạ lần lượt tới
sgp và dal.
Phản hồi
integer
ID đăng ký (cần thiết để hủy đăng ký)
Thông báo
Sau thông báo xác nhận JSON, các thông báo được phân phối dưới dạng khung WebSocket nhị phân (không phải JSON). Các xác nhận trước của Helius và BAM dùng chung một bố cục. Mỗi khung là một bố cục byte được đóng gói, chứa một giao dịch duy nhất:
Payload không có trường nguồn. Không suy luận nguồn gốc BAM từ
tx_index = 0, vì các xác nhận trước của Helius có thể chứa cùng các giá trị đó.
Xác nhận trước là một tín hiệu sớm, không phải sự đảm bảo. Giao dịch chưa được ghi nhận onchain và vẫn có thể thất bại hoặc bị loại bỏ. Hãy xác nhận giao dịch đã được ghi nhận thông qua các bước kiểm tra mức cam kết tiêu chuẩn trước khi coi giao dịch là hoàn tất.
Giải mã giao dịch
Các byte giao dịch được chuyển tiếp chính xác như cách validator tuần tự hóa chúng, theo mã hóa wire tiêu chuẩn dành cho phiên bản giao dịch. Các giao dịch legacy và v0 sử dụng bố cục chữ ký trước dobincode tạo ra. Giao dịch v1 (SIMD-0385) sử dụng bố cục thông điệp trước với chữ ký ở cuối, nên bincode không xử lý được payload v1.
Hãy dùng bộ giải mã xử lý được mọi phiên bản. Trong Rust, agave-transaction-view phân tích tại chỗ các giao dịch legacy, v0 và v1 và là lựa chọn được đề xuất; wincode với VersionedTransaction của Solana SDK hiện hành cũng hoạt động. Trong JavaScript, hãy đảm bảo phiên bản thư viện hỗ trợ giao dịch v1. Xem hướng dẫn để tham khảo ví dụ Rust.
Thông báo trùng lặp
Các xác nhận trước của Helius và BAM được loại bỏ trùng lặp riêng theo từng nguồn, không phải giữa các nguồn. Một tỷ lệ nhỏ giao dịch đến Helius qua cả hai nguồn, vì vậy bạn có thể nhận cùng một chữ ký hai lần và hai bản sao có thể báo cáo các slot khác nhau. Hãy loại bỏ trùng lặp theo chữ ký ở phía máy khách và đảm bảo các hành động được kích hoạt bởi giao dịch có tính lũy đẳng. Xem hướng dẫn.Giá
Preconfirmations yêu cầu gói Professional trở lên và có giá 10 tín dụng cho mỗi thông báo — một thông báo cho mỗi giao dịch được truyền phát. Xem Tín dụng để biết chi tiết. Phí được tính theo từng thông báo, không phải theo từng chữ ký duy nhất. Một giao dịch được phân phối bởi cả Helius và BAM sẽ được tính hai lần. ĐặtincludeBam: false nếu bạn chỉ muốn nhận các xác nhận trước của Helius.
Liên quan
Preconfirmations Overview
Preconfirmations là gì và nằm ở đâu trong quy trình xử lý của validator.
preconfUnsubscribe
Dừng một lượt đăng ký bằng ID của lượt đăng ký đó.